…dateSdk switch

The ValidateSdk stage already self-bootstraps arcade with the newly produced SDK. Change its
rebuild from /p:Test=false to /p:RunNonHelixTestsOnly=true so it also runs the ported Arcade SDK
validation RepoTests against the new SDK, and publish their results (enablePublishTestResults).

Add a runValidateSdk escape hatch (default true), exposed at queue time in azure-pipelines.yml,
that gates the whole ValidateSdk stage and its place in post-build publishDependsOn so a
badly-broken arcade can still ship a fix.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…eparate Latest promotion

Addresses review feedback on the official-build validation design (dotnet#17046):

- Do NOT run the RepoTests in the official build (revert ValidateSdk to /p:Test=false); the
  RepoTests run in the PR build only.
- ValidateSdk stage now runs three validations of the newly produced SDK in parallel:
  * self-build  (eng/validate-sdk.yml)      - rebuild arcade with the new SDK,
  * signing     (eng/validate-signing.yml)  - sign a curated set of artifact types with the new
                                              SignTool (ported arcade-validation Resources + jobs,
                                              cross-OS, after update-packagesource bumps the new SDK),
  * promotion   (eng/validate-promotion.yml)- validate promotion works with the new arcade.
- Separate the promotion *test* from the final promotion:
  * eng/validation/validate-promotion.ps1 promotes to 'General Testing' from a branch bumped to the
    new arcade (uses the current build commit; no --publishing-infra-version) - part of ValidateSdk.
  * eng/validation/promote-to-latest.ps1 promotes to '.NET Eng - Latest' with the default arcade in a
    separate PromoteToLatest stage that runs on build success, gated on ValidateSdk only when it is
    enabled - so a build can still be promoted when validation is disabled.
- Remove the usePrebuiltArcadeForPublishing parameter (the new-arcade-ness now lives only in the
  promotion test).

Main only: release branches keep using dotnet/arcade-validation for promotion.

NOTE: the signing and promotion validations run only in the internal official build and cannot be
validated locally or in PR; they need @dotnet/dnceng review and a real run.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

The signing-validation inputs already exist as SignTool unit-test resources
(src/Microsoft.DotNet.SignTool.Tests/Resources), which is a superset of arcade-validation's set.
Point eng/validate-signing.yml at that folder with a curated file list instead of duplicating the
binaries under eng/validation/resources, and remove the duplicated resources.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

The VSIX staging step was only on the Windows signing job; arcade-validation copies the .vsix
inputs in all three OS jobs. Add it to Linux and macOS so their sign runs also exercise VSIX signing.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…a parameters

- promote-to-latest.ps1 was essentially a single 'darc add-build-to-channel' call; inline it into the
  PromoteToLatest stage (Get-Darc from tools.ps1) and remove the script.
- Hoist the signing-validation package/VSIX copy lists into template parameters
  (signingTestPackages / signingTestVSIXes) so they are defined once and shared by all three jobs.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

darc update-dependencies --packages-folder scans NON-recursively
(Directory.GetFiles(path, "*.nupkg")), but arcade's build artifacts nest the
produced packages under packages/<config>/NonShipping. Pointing darc at the
build_stage_artifacts root therefore found zero nupkgs and reported "Found no
dependencies to update" (leaving global.json on the bootstrap SDK).

Recursively locate the produced Microsoft.DotNet.Arcade.Sdk / Helix.Sdk nupkgs
(arcade only produces nonshipping packages; these are the only arcade-produced
deps tracked in Version.Details.xml), copy them into a single flat temp folder,
and point darc at that. Clean up the temp folder afterward.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Simpler than gathering into a temp flat folder: arcade produces only
nonshipping packages, so Arcade.Sdk and Helix.Sdk are both in the same
packages/<config>/NonShipping folder. Point darc's (non-recursive)
--packages-folder at the directory containing the produced Arcade.Sdk nupkg.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

darc update-dependencies resolves asset locations from Maestro/BAR, so it needs
an Azure AD token. In a plain powershell step darc's AzureCliCredential timed
out ("Azure CLI authentication timed out") because there was no az login
context. Run the darc step under AzureCLI@2 with the "Darc: Maestro Production"
service connection (same pattern as the promotion validation) so darc can
authenticate.

Note: the nonshipping-folder fix worked - darc found the packages and got past
"no dependencies to update"; this addresses the next blocker (auth).

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Testing confirmed darc update-dependencies --packages-folder DOES bump
global.json (Arcade.Sdk/Helix.Sdk are tracked in Version.Details.xml), but it
also re-syncs eng/common from the remote arcade repo at the built commit, which
requires a GitHub PAT and the commit to exist on github.com/dotnet/arcade. That
makes it work only on official main builds, not dev/PR builds.

Per that finding, keep the self-build on the file-based use-built-sdk.ps1 bump
(regex bump of global.json + local feed), which works identically on main and
PR with no darc/BAR/GitHub/network dependency. Remove the -AddFeedOnly switch
(now unused) and the darc-based update-sdk-versions.ps1 helper.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

use-built-sdk.ps1:
- Guard against a missing <packageSources> element with a clear error.
- Make the local-feed injection idempotent: remove any existing arcade-local-*
  <add>/<packageSource> entries before adding, so re-running in the same
  workspace doesn't create duplicate keys (which NuGet rejects).

validate-promotion.ps1:
- Throw a clear error if `darc get-build` returns an empty result (avoids a
  StrictMode null-reference later in the channel gate).
- Force-push the throwaway per-build validation branch so a leftover branch
  from a prior failed run doesn't cause a non-fast-forward push failure.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

The target channel ('.NET Eng - Latest') was duplicated across the promotion
stage/job/task displayNames and the darc add-build-to-channel command, and the
promotion source branch ('refs/heads/main') was inlined in the stage gate.
Move both to top-level parameters (promotionChannel, promotionSourceBranch) so
each value is defined once and reused, per PR review feedback.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>